BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ
News Articles Presentations Podcasts Guides

Topics

Choose your language

QCon San Francisco - image
QCon San Francisco

Level up your software skills by uncovering the emerging trends you should focus on. Register now.

 QCon London - image
QCon London

Discover emerging trends, insights, and real-world best practices in software development & tech leadership. Join now.

 QCon London - image
InfoQ Dev Summit Boston

Learn how senior software developers are solving the challenges you face. Register now with early bird tickets.

 The Software Architects Newsletter - image
The Software Architects' Newsletter

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage News Article: SOA Governance: An Enterprise View

Article: SOA Governance: An Enterprise View

Bookmarks

Aug 20, 2008 4 min read

Write for InfoQ

Feed your curiosity. Help 550k+ global
senior developers
each month stay ahead.Get in touch

In a new article, SOA architect Michael Poulin explains the necessity for SOA governance to ensure an SOA initiative's success, and explains the role the OASIS SOA Reference Model and the accompanying SOA Reference Architecture assign to SOA Governance. Michael observes SOA governance specifics from the enterprise perspective and illustrates them with several examples of SOA Governance policies.

In addition to the SOA Reference Model, Michael introduces the OASIS SOA Reference Architecture, currently in public review:

The SOA RA PRD 1 has recognised the role of enterprise social structure within SOA. Indeed, actions of the participants of the service interaction – service consumers and providers – have business or technical meaning only to the people and organisational units “with needs” and those “with capabilities”. As a consequence of this, we may say that if a social structure changes, the same actions may get different meaning than before. Even more, if a consumer expects the same meaning of the service actions in different social structures, it is likely that the service has to behave differently and provide different results (or RWE) in different social structures to meet such expectation.

Michael points out that SOA Governance is not the only governance an enterprise has to be concerned with:

Nevertheless, SOA Governance does not replace Enterprise Governance, or Business Governance, or IT Governance. We have to remember that there is a world besides SOA.

According to the author, SOA Governance applies to four major aspects of service structure and service use:

  • Service structure – the minimal set of elements that constitute a service within element relationship and operational models (development, integration and deployment policies)
  • SOA infrastructure – the “plumbing” that provides utility functions that enable and support the use of the service (deployment and run-time policies)
  • Service inventory – the requirements on a service to permit it to be accessed within the infrastructure via public interfaces, manually and automatically (management policies)
  • Participant interaction – the consistent expectations with which all participants of the service interaction are expected to comply (reachability and run-time policies)

Michael concludes with examples of SOA Governance policies that have proven to be useful to him in the past:

Areas of Applicability

Policy Examples

Governance Process

  • Service Governance Roles include: Service Owner, Service Provider, Service Consumer, Service Steward, Service Registrar, etc.

  • Service Governance Board includes representation from business, architecture, delivery and systems operations groups. The governance group is responsible for:

    • Defining and maintaining governance directives and policies

    • Granting of design and implementation exceptions when possible

    • Compliance reporting to the Management.

  • Governance policies and controls may be monitored and enforced by the Service Registrar as well as by corresponding Review Boards and Architectural Bodies

Development Stage

  • Design and development of the service has to have very strong reason(s) to be allowed going with an exception from the policies compliance

  • Service design has to be based on and take into consideration business execution context of the required business task. The business execution context should be able to outline what elements of the service are likely to be changed in the future.

  • Service design has to consider recommendations on the business operational scenarios for those who might use the service. If such scenarios are identified, business approval and sign-off are required.

  • Services should minimise or totally hide their internal constraints from the consumers.

  • A Service has to compensate for internal problem processing transparently to the consumers and never expose its internal execution constraints on to the consumers.

  • Service interfaces and service body (implementation) must adhere to the corporate security policies

  • The Service owner must provide service classification (business, infrastructure, etc.) and scope definition (business unit, enterprise, external, etc.) for each released service

  • “Avoid setting up processes that demo well for three services without considering how it will work for 300” (SOA RA PRD 1).


Production Stage

  • All business services are required to maintain a Service Contract for each consumer they support.

  • All services are required to publish Service Descriptions

  • If the service does not require a Service Contract, its service level agreement has to be published in the Service Description

  • All services are required to adhere to a versioning strategy that provides all consumers with opportunities to migrate to the latest supported version(s) of a service.

  • All Service Descriptions have to be published in the Service Description Repository

  • All run-time service policies have to be published in the Service Policy Repository

  • Run-time service Policies may refer to other policies. Policies may be applied by the Policy Enforcement Point (PEP) interceptors and enforced by the Policy Decision Point (PDP) mechanisms

  • “…consider whether the display of status and activity for a small number of services will also be effective for an operator in a crisis situation looking at dozens of services, each with numerous, sometimes overlapping and sometimes differing activities” (SOA RA PRD 1)

Check out Michael Poulin's article, "SOA Governance: An Enterprise View" for more information.

Rate this Article

Adoption
Style

This content is in the Enterprise Architecture topic

Related Topics:
BT